1. Field of the Invention
The present invention relates to object-oriented computer systems having classes that are dynamically loaded at runtime. More particularly, the present invention relates to a method and apparatus for collocating dynamically loaded program files.
2. Background
Programming languages may be classified according to the time at which program units required for program execution are loaded. Dynamic languages allow program units to be loaded dynamically as they are needed. Static languages require that all program units required for program execution be loaded prior to program execution. The “late binding” provided by dynamic languages means that programs only grow as large as they need to be at runtime. Additionally, dynamic languages also enhance program modularity because dynamic languages make fewer compiled-in assumptions about the implementation of data structures than static, early-binding languages like C or C++.
FIG. 1 is a block diagram that illustrates dynamically loaded program files. A loader 10 first loads the main program unit. Program execution proceeds until a program unit that has not already been loaded is referenced. At this point, the loader 10 loads the referenced program unit contained in a file. The loader 10 loads the files on an as needed basis. Dynamically loading program files is described in more detail with reference to FIG. 1A.
Turning now to FIG. 1A, a flow diagram that illustrates dynamically loading program files is presented. At reference numeral 400, a runtime loader is invoked to execute the main program unit. When the runtime loader encounters a reference to a program unit that has not already been loaded (405), the runtime loader searches known input sources until either the program unit is found, or until all input sources have been exhausted (410). The runtime loader loads the program unit (420) if it is found (415).
The dynamic language program files loaded may be categorized many ways. The files loaded are frequently categorized as either system files 12 or application files 14. The term “system files” 12 typically refers to files containing program units supplied as part of a particular execution environment. Conversely, the term “application files” 14 typically refers to files containing program units not supplied as part of a particular execution environment. The system files 12 and application files 14 may be individual program files that are loaded and executed directly. The system files 12 and application files 14 may also be libraries containing one or more individual program files that are first extracted from a library and then loaded.
The Java™ language is one example of a dynamic language. In Java™ technology, a class loader loads classes dynamically one at a time, as they are needed. Any Java™ class can be loaded into a running Java™ interpreter at any time, possibly even over the network. When the Java™ application or applet is loaded in this manner, however, each of the files is transferred in uncompressed form using a separate request, making the process relatively inefficient.
Each Java™ execution environment includes a collection of services and libraries referred to as the Java™ Development Kit (JDK). New applications are created by adding services and libraries that build upon the standard JDK. As these new Java™ services and libraries are developed, their functionality is typically provided to developers as a set of packages provided in different JAR (Java™ ARchive) files, which are archives of files used by a Java™ application. A JAR file allows compressed versions of one or more files to be combined into a single JAR file. Each JAR file also includes a “manifest” file that contains meta-information about the files in the archive.
To use a JAR file, the JAR file is specified as the value of the archive attribute of an applet or application:                <APPLET archive=“sound.jar” code=“Soundmap.class” width=288 height=288>        . . .        </APPLET>        
The “code” attribute tells the browser which of the class files in the archive contains the main method to be executed. The “archive” attribute specifies where to look for files. The archive attribute may specify a list of JAR files. The Web browser or applet viewer searches these archives for any files the applet requires. If a file is not found in an archive, the browser attempts to load the file from the Web using a new HTTP request.
Java™ applications wishing to use new services and libraries must ensure the appropriate JAR files are available to the application at runtime. This requirement is made difficult by the fact that JAR files may be located in multiple places and on multiple servers. Each JAR file may also contain extra Java™ classes or packages that the Java™ application does not use but which are automatically loaded as a part of application initialization.
Development of an application program typically involves creating multiple program units that reference other program units. Each referenced program unit may in turn reference other program units. In a dynamic language environment, each referenced program unit must be loaded at run time before the referenced unit is used. Loading more program units than necessary decreases execution efficiency. Often, removing the reference to the program unit may prevent loading a program unit at run time. For example, a user or developer may create a local method to perform a task, rather than invoke an external program unit. Accordingly, a need exists in the prior art for a method and apparatus for determining which program units are loaded during execution of a dynamically loaded program.
Additionally, loading program units that are unneeded and loading uncompressed program units increases startup time and increases the memory footprint of the running application. Accordingly, a further need exists in the prior art for a method and apparatus for collocating only the program units required for executing a dynamic language program.